home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1668 < prev    next >
Text File  |  1995-07-26  |  5KB  |  172 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Estrin
  8. Request for Comments: 1668                                           USC
  9. Category: Informational                                            T. Li
  10.                                                            Cisco Systems
  11.                                                               Y. Rekhter
  12.                                   T.J. Watson Research Center, IBM Corp.
  13.                                                              August 1994
  14.  
  15.  
  16.                  Unified Routing Requirements for IPng
  17.  
  18. Status of this Memo
  19.  
  20.    This memo provides information for the Internet community.  This memo
  21.    does not specify an Internet standard of any kind.  Distribution of
  22.    this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This document was submitted to the IETF IPng area in response to RFC
  27.    1550.  Publication of this document does not imply acceptance by the
  28.    IPng area of any ideas expressed within.  Comments should be
  29.    submitted to the big-internet@munnari.oz.au mailing list.
  30.  
  31. 1. IPng Requirements
  32.  
  33.    The following list provides requirements on the IPng from the
  34.    perspective of the Unified Routing Architecture, as describe in RFC
  35.    1322.
  36.  
  37.    1. To provide scalable routing, IPng addressing must provide support
  38.       for topologically significant address assignment.
  39.  
  40.    2. Since it is hard to predict how routing information will be
  41.       aggregated, the IPng addressing structure should impose as few
  42.       preconditions as possible on the number of levels in the hierarchy.
  43.       Specifically, the number of levels must be allowed to be different
  44.       at different parts in the hierarchy. Further, the levels must not
  45.       be statically tied to particular parts (fields) in the addressing
  46.       information.
  47.  
  48.    3. Hop-by-hop forwarding algorithm requires IPng to carry enough
  49.       information in the Network Layer header to unambiguously determine
  50.       a particular next hop. Unless mechanisms to compute
  51.       context-sensitive forwarding tables and provide consistent
  52.       forwarding are defined, the requirement assumes the presence of
  53.       full hierarchical addresses.  Therefore, IPng packet format must
  54.       provide efficient determination of the full hierarchical
  55.  
  56.  
  57.  
  58. Estrin, Li & Rekhter                                            [Page 1]
  59.  
  60. RFC 1668         Unified Routing Requirements for IPng       August 1994
  61.  
  62.  
  63.       destination address.
  64.  
  65.    4. Hierarchical address assignment should not imply strictly
  66.       hierarchical routing. Therefore, IPng should carry enough
  67.       information to provide forwarding along both hierarchical and
  68.       non-hierarchical routes.
  69.  
  70.    5. The IPng packet header should accommodate a "routing label" or
  71.       "route ID". This label will be used to identify a particular FIB
  72.       to be used for packet forwarding by each router.
  73.  
  74.       Two types of routing labels should be supported: "strong" and
  75.       "weak".
  76.  
  77.       When a packet carries a "strong" routing label and a router does
  78.       not have a FIB with this label, the packet is discarded (and an
  79.       error message is sent back to the source).
  80.  
  81.       When a packet carries a "weak" routing label and a router does not
  82.       have a FIB with this label, the packet should be forwarded via a
  83.       "default" FIB, i.e., according to the destination address. In
  84.       addition, the packet should carry an indication that somewhere
  85.       along the path the desired routing label was unavailable.
  86.  
  87.    6. IPng should provide a source routing mechanism with the following
  88.       capabilities (i.e., flexibility):
  89.  
  90.        - Specification of either individual routers or collections of
  91.          routers as the entities in the source route.
  92.  
  93.        - The option to indicate that two consecutive entities in a
  94.          source route must share a common subnet in order for the
  95.          source route to be valid.
  96.  
  97.        - Specification of the default behavior when the route to
  98.          the next entry in the source route is unavailable:
  99.  
  100.        - The packet is discarded, or
  101.  
  102.        - The source route is ignored and the packet is forwarded based
  103.          only on the destination address (and the packet header will
  104.          indicate this action).
  105.  
  106.        - A mechanism to verify the feasibility of a source route.
  107.  
  108. Security Considerations
  109.  
  110.    Security issues are not discussed in this memo.
  111.  
  112.  
  113.  
  114. Estrin, Li & Rekhter                                            [Page 2]
  115.  
  116. RFC 1668         Unified Routing Requirements for IPng       August 1994
  117.  
  118.  
  119. Authors' Addresses
  120.  
  121.    Deborah Estrin
  122.    University of Southern California
  123.    Computer Science Department, MC 0782
  124.    Los Angeles, California 90089-0782
  125.  
  126.    Phone: (310) 740-4524
  127.    EMail: estrin@usc.edu
  128.  
  129.  
  130.    Tony Li
  131.    cisco Systems, Inc.
  132.    1525 O'Brien Drive
  133.    Menlo Park, CA 94025
  134.  
  135.    EMail: tli@cisco.com
  136.  
  137.  
  138.    Yakov Rekhter
  139.    T.J. Watson Research Center IBM Corporation
  140.    P.O. Box 218
  141.    Yorktown Heights, NY 10598
  142.  
  143.    Phone:  (914) 945-3896
  144.    EMail:  yakov@watson.ibm.com
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Estrin, Li & Rekhter                                            [Page 3]
  171.  
  172.